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REMARKS/ARGUMENTS 

On page 3 of the Official Action, claims 1, 8, and 16 were rejected under 35 U.S.C. 
102(e) as being anticipated by Kouznetsov et al. U.S. 7,096,501. On page 4 of the Official 
Action, claims 1-3, 6, 8-10, and 16 were rejected under 35 U.S.C. 102(e) as being anticipated by 
Smithson. et al. U.S. 6,802,012. On page 5 of the Official Action, claims 1-16 and 18-28 were 
rejected under 35 U.S.C. 102(e) as being anticipated by McAfee ("GroupShield and the 
Microsoft Virus Scanning API"). On page 10 of the Official Action, claims 5-7, 12, 24, and 16 
were rejected under 35 U.S.C. 103(a) as being unpatentable over Smithson in view of McAfee. 
On pages 11-12 of the Official Action, claim 17 was rejected under 35 U.S.C. 103(a) as being 
unpatentable over McAfee in view of AAPA; namely, Frank S. Caccavale, Publication No. US- 
2002-0129277-A1. 

In reply to the claim rejections, claims 1-5 have been canceled, claim 6 has been re- 
written in independent form including all of the limitations of its independent base claim 1 (there 
being no intervening claims), claims 8-10 have been canceled, claim 11 has been re-written in 
independent form including all of the limitations of its independent base claim 8 (there being no 
intervening claims), claims 16-21 have been canceled, and claim 22 has been re-written in 
independent form including all of the limitations of its independent base claim 16 (there being no 
intervening claims). Otherwise, applicant respectfully traverses the rejections, for the specific 
reasons set out below. 

The remaining claims are directed generally to operation of a plurality of virus checkers 
(24, 25, 26 in applicant's FIG. 1). On-demand anti-virus scan requests and on-access anti-virus 
scan requests are distributed to the virus checkers so that the virus checkers perform on-demand 
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anti-virus scanning concurrent with on-access anti-virus scanning. "On-access" virus scanning 
occurs when a specified trigger occurs, such as when a user accesses a file marked "unchecked." 
(Applicant's specification, page 4, lines 7-8.) "On-demand" virus scanning is typically 
scheduled when a new virus is discovered, when new unchecked files are migrated to a file 
server, or prior to archiving or backing-up unchecked files. (Applicant's specification, page 4, 
lines 8-10.) 

The remaining claims are specifically directed to on-demand request chunking (box 67 in 
applicant's FIG. 3; steps 108-109 in applicant's FIG. 7). For example, outstanding "on-demand" 
virus scan requests are added to the shared queue when the number of requests in the shared 
queue falls below a threshold. The threshold is selected to provide a relatively continuous flow 
of requests to the virus checkers without significantly degrading the response time of the virus 
checkers for responding to the "on-access" requests. Moreover, it is desirable to add outstanding 
"on-demand" virus scan requests to the shared queue in manageable "chunks", and to wait until 
the virus scan requests in each chunk have been serviced before sending another chunk of "on- 
demand" virus scan requests. (Applicant's specification, page 12, lines 15-23.) The on-demand 
anti-virus scan requests are grouped into chunks. Each of the chunks includes multiple ones of 
the on-demand anti-virus scan requests. (Applicant's specification, page 13, lines 13-22; page 
16 lines 4-23). In a general case of "N" virus checkers and "M" anti-virus threads, for example, 
the chunk size is the product (M*N), and the threshold is set to one-half of the chunk size. 
(Applicant's specification, page 13, lines 20-22.) A near-empty queue threshold (TH1) and a 
relatively small chunk size will result in the on-demand requests being placed entirely in 
background during high loading conditions. However, a larger chunk size and a larger queue 
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threshold will tend to keep the virus checkers busy under diverse loading conditions. 
(Applicant's specification, page 18, lines 13-17.) The chunking can keep multiple virus 
checkers busy scanning files in a file system without substantially reducing the availability of the 
virus checkers for on-access virus checking. (Applicant's specification, page 18 line 22 to page 
19 line 6.) 

The applicant's claims are not anticipated by Smithson 

The remaining claim 6 stands rejected under 35 U.S.C. 102(b) as anticipated by 
Smithson. 

Smithson discloses a method of operating a computer for on-demand anti-virus scanning 
and on-access virus scanning of computer files. (Smithson, Abstract.) On-demand anti-virus 
scan requests and on-access anti-virus scan requests are combined in a virus scan request queue. 
Smithson's virus scan request queue is called a "pending list" in step 18 of Smithson's FIG. 2. 
This "pending list" is shown in Smithson's FIG. 3 for the case of on-access requests rather than 
on-demand accesses. (Smithson, col. 5 lines 5-22.) The scan requests in the pending list, 
however, are not distributed to a plurality of virus checkers. Instead, the scan requests in the 
pending list are sequentially selected and serviced one at a time in step 24 of Smithson's FIG. 4. 
(Smithson, col. 5, lines 23-30.) Therefore, at any given time that the Scan Engine 34 of 
Smithson's FIG. 5 is performing an anti-virus scan, either an on-demand anti-virus scan or an 
on-access anti-virus scan is being performed by the Scan Engine 34. (Smithson, col. 5, lines 46- 
54.) 
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Applicant's claim 6 further recites "grouping the on-demand anti-virus scan requests into 
chunks, each of the chunks including multiple ones of the on-demand anti-virus scan requests, 
and placing the chunks onto the virus scan request queue." The placement of chunks of plural 
on-demand scan requests on the virus scan request queue, instead of individual on-demand scan 
requests, is shown in applicant's FIG. 7, steps 108, 109, and 110, as described in applicant's 
specification, page 16 lines 4-8 and 18-23. 

With respect to claim 6, page 5 of the Official Action says: "Figure 2 of Smithson teaches 
placing on-demand scan requests into a queue, Figure 3 shows the 'chunks'." However, 
Smithson does not disclose " placing the chunks onto the virus scan request queue." Instead, 
Figure 2 of Smithson shows that one on-demand or on-access scan request is received in step 10 
and then written to the virus scan request queue in step 18. Thus, individual scan requests and 
not chunks of plural scan requests are placed on the virus scan request queue of Smithson. See 
Smithson Col. 4 line 50 to Col. 5 line 5. Moreover, the "Time Requested" stamps in FIG. 3 are 
an indication that the plurality of requests shown in the virus scan request queue of FIG. 3 were 
placed onto the virus scan requests individually at different respective times. 

The applicant's claims are not anticipated by McAfee 

The remaining claims 6-7, 11-15, and 22-28 stand rejected under 35 U.S.C. 102(e) as 
being anticipated by McAfee ("GroupShield and the Microsoft Virus Scanning API"). 

McAfee describes a virus scanning API 2.0 said to have been released as an upgrade to 
Microsoft Exchange 2000 in Service Pack 1 to provide a number of enhancements including 
priority based queuing, multithreaded queue processing, and enhanced background scanning. As 
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a client attempts to gain access to an Exchange item in the Exchange Server, a comparison is 
made to ensure that the message body and attachment (if present) has been scanned by the 
current virus signature file. If the content has not been scanned by the current virus signature 
file, then the corresponding item is submitted to GroupShield for scanning before that item is 
released to the client. In virus scanning API 2.0, a single queue processes all of the message 
body and attachment data. On-access requests are submitted as high-priority items. This queue 
is now serviced by a series of threads (the default number of threads is 2* number_of_processors 
+ 1), with high-priority items always taking precedence. (McAfee, page 3.) Virus scanning API 
2.0 also includes on-demand proactive scanning of messages. Items are submitted to a common 
information store queue as they are submitted to the information store. Each of these items 
receives a low priority in the queue, so that these items do not interfere with the scanning of the 
high-priority items. When all of the high-priority items have been scanned, virus scanning API 
2.0 begins to scan low-priority items. The priority of items is dynamically upgraded to high 
priority if a client attempts to access the item when the item is in the low-priority queue. A 
maximum of 30 items can exist at one time in the low priority queue, which is determined on a 
first in, first out basis. (McAfee, page 4.) 

With respect to "chunks" in McAfee, page 6 and also page 7 of the Official Action says: 
"Page 3 [of McAfee] shows on-access scan requests being placed within 'chunks' of on-demand 
scan requests." Applicant respectfully disagrees. Page 3 of McAfee shows (under the heading 
"Global Scanning Queue") a first box in which "Unscanned items are all placed in the queue 
with the same priority ."; a second box in which "However, if a user accesses an item, it attains a 
high priority and jumps to the front of the queue."; and a third box in which "If a user saves an 
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item to a folder, it is given a low priority." (Page 4 further explains that the on-demand requests 
with the same low priority are maintained as a first-in first-out queue.) Therefore, in applicant's 
view, the first box on page 3 of McAfee shows the low-priority queue of on-demand scan 
requests in the Global scanning queue, and the second box shows a scan request being moved 
from the low-priority queue to the front of the Global Scanning Queue when the scan request is 
promoted from an on-demand scan request to an on-access scan request. Applicant does not see 
"grouping the on-demand anti-virus scan requests into chunks, each of the chunks including 
multiple ones of the on-demand anti-virus scan requests, and placing the chunks onto the virus 
scan request queue" as recited in applicant's claim 6. 

Applicant also does not see where McAfee discloses "inhibiting the distribution of 
multiple ones of the on-demand anti-virus scan requests from at least one of the chunks to the 
virus checkers until completion of anti-virus scanning for the anti-virus scan requests in a prior 
one of the chunks" as recited in Applicant's claim 11. Instead, in McAfee, if an on-demand 
request is next in line in McAfee's Global Scanning Queue and a scanner thread has just finished 
using a processor to satisfy an anti-virus scan request, the scanner thread would then begin 
scanning the on-demand request that is next in line in McAfee's Global Scanning Queue. 

Applicant also does not see where McAfee discloses "grouping the on-demand anti-virus 
scan requests into chunks, each of the chunks including multiple ones of the on-demand anti- 
virus scan requests, and for each chunk, checking whether the number of anti-virus scan requests 
on the virus checking queue is less than a threshold, and upon finding that the number of anti- 
virus scan requests on the virus checking queue is less than the threshold, placing said each 
chunk on the virus scan request queue" as recited in applicant's claim 12. Instead, in the 
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proactive scanning of McAfee, when an item is submitted to the information store, an on-demand 
scan request of the item is placed on the low-priority queue so long as the queue is not full (a 
maximum of 30 items can exist at one time in the low-priority queue). If an on-demand scan 
request of the item is not placed on the low-priority queue when an item is submitted to the 
information store because the queue is full at that time, the item still could be scanned later as a 
result of background scanning or on-access scanning. In short, in McAfee, individual scan 
requests and not chunks of plural scan requests are placed on the queue so long as the queue is 
not full. 

Applicant also does not see where McAfee discloses "inhibiting the placement of at least 
one of the chunks onto the virus scan request queue until completion of anti-virus scanning for 
the anti-virus scan requests in a prior one of the chunks" as recited in applicant's claims 7 and 
15. Applicant respectfully submits that it is unreasonable to interpret "inhibiting the placement 
of at least one of the chunks onto the virus scan request queue until completion of anti-virus 
scanning for the anti-virus scan requests in a prior one of the chunks" as simply not placing an 
individual on-demand scan request on the queue of McAfee if the queue is full. For example, if 
the low-priority queue of McAfee contains a plurality of scan requests and this plurality of scan 
requests is considered a chunk (as proposed in the Official Action on page 7 with respect to the 
independent base claim 12), then in McAfee there is no inhibiting placement of a new on- 
demand scan request on the low-priority queue of McAfee until the low-priority queue is empty. 
Instead, so long as the queue is not full, a new on-demand scan request would be placed on the 
queue of McAfee. 
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Applicant does not see the chunking feature of applicant's claim 22 in McAfee for the 
same reasons discussed above with respect to claim 6. 

Applicant does not see the chunk placement inhibiting feature of applicant's claim 23 in 
McAfee for the same reasons discussed above with respect to applicant's claim 7. 

Applicant does not see the chunking feature of applicant's claim 24 in McAfee for the 
same reasons as discussed above with respect to applicant's claim 6. 

Applicant does not see the chunk placement threshold feature of applicant's claim 27 in 
McAfee for the same reasons as discussed above with respect to applicant's claim 12. Placing a 
chunk of plural on-demand scan requests on a virus scan request queue upon finding that the 
number of anti-virus scan requests on the virus checking queue is less than a threshold is 
different from placing an individual on-demand scan request on the queue upon finding that the 
queue is not full. 

Applicant does not see the chunk placement inhibiting feature of applicant's claim 28 in 
McAfee for the same reasons as discussed above with respect to applicant's claim 7. 

The applicant's claims are not obvious from Smithson in view of McAfee 

The remaining claims 6-7, 12, and 24 stand rejected under 35 U.S.C. 103(a) as being 
unpatentable over Smithson in view of McAfee. Applicant respectfully traverses. As discussed 
above, with respect to claim 6, neither Smithson nor McAfee discloses "grouping the on-demand 
anti-virus scan requests into chunks, each of the chunks including multiple ones of the on- 
demand anti-virus scan requests, and placing the chunks onto the virus scan request queue." 
(Emphasis added.) 
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As discussed above, with respect to claim 7, neither Smithson nor McAfee discloses 
"inhibiting the placement of at least one of the chunks onto the virus scan request queue until 
completion of anti-virus scanning for anti-virus scan requests in a prior one of the chunks." 
"Inhibiting the placement of at least one of the chunks onto the virus scan request queue until 
completion of anti-virus scanning for the anti-virus scan requests in a prior one of the chunks" is 
different from simply not placing an individual on-demand scan request on a queue of scan 
requests if the queue is full. 

Applicant's claim 12 includes the chunk placement feature of applicant's claim 6 and the 
chunk placement inhibiting feature of applicant's claim 7. Therefore applicant's claim 12 is 
distinguished from the proposed combination of Smithson and McAfee for the reasons discussed 
above with respect to applicant's claims 1 and 7. 

Applicant's claim 24 includes the chunk placement feature of applicant's claim 6, and 
therefore is distinguished from the proposed combination of Smithson and McAfee for the 
reasons discussed above with respect to applicant's claim 6. 

In short, neither the chunk placement feature nor the chunk placement inhibiting feature 
of applicant's claims result from the proposed combination of Smithson and McAfee. Smithson 
appears entirely satisfactory for its intended purpose of queuing on-access anti-virus requests and 
on-demand anti- virus requests for giving priority to the on-access requests in a system having a 
single virus scanner. McAfee also appears entirely satisfactory for its intended purpose of 
queuing on-access anti- virus requests and on-demand anti-virus requests for giving priority to the 
on-access requests in a system having multiple processors for anti-virus scanning. There does 
not appear to be anything in Smithson suggesting modification of McAfee to arrive at applicant's 
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chunk placement feature or applicant's chunk placement inhibiting feature. There does not 
appear to be anything in McAfee suggesting modification of Smithson to arrive at applicant's 
chunk placement feature or applicant's chunk placement inhibiting feature. It also appears that if 
one were told to modify Smithson in view of McAfee, the result would be similar to McAfee 
itself. In other words, servicing the queue of Smithson with multiple threads executed by 
multiple processors is similar to what McAfee discloses. 

When determining whether a claim is obvious, an examiner must make "a searching 
comparison of the claimed invention - including all its limitations - with the teaching of the 
prior art." In re Ochiai . 71 F.3d 1565, 1572 (Fed. Cir. 1995) (emphasis added). Thus, 
"obviousness requires a suggestion of all limitations in a claim." CFMT. Inc. v. Yieldup Intern. 
Corp. . 349 F.3d 1333, 1342 (Fed. Cir. 2003) ( citing In re Rovka . 490 F.2d 981, 985 (CCPA 
1974)). Moreover, as the Supreme Court stated, " there must be some articulated reasoning with 
some rational underpinning to support the legal conclusion of obviousness." KSR Int'l v. 
Teleflex Inc .. 127 S. Ct. 1727, 1741 (2007) (quoting In re Kahn . 441 F.3d 977, 988 (Fed. Cir. 
2006) (emphasis added)). A fact finder should be aware of the distortion caused by hindsight bias 
and must be cautious of arguments reliant upon ex post reasoning. See Id., 127 S. Ct. at 1742, citing 
Graham , 383 U. S. at 36 (warning against a "temptation to read into the prior art the teachings of the 
invention in issue" and instructing courts to "guard against slipping into the use of hindsight."). 

The problem that the inventor is trying to solve must be considered in determining 
whether or not the invention would have been obvious. The invention as a whole embraces the 
structure, properties and problems it solves. In re Wright . 848 F.2d 1216, 1219, 6 U.S.P.Q.2d 
1959, 1961 (Fed. Cir. 1988). Neither Smithson nor McAfee recognizes that there is a problem 

18 



Ser.No. 10/748,008 

Amendment in Reply to OA of Dec. 29, 2008 



with servicing a virus scan request queue that could be or should be solved by the applicant's 
chunk placement feature or applicant's chunk placement inhibiting feature. As discussed above, 
by managing on-demand virus scan requests in chunks of plural on-demand requests, the 
applicant's invention can keep multiple virus checkers busy scanning files in a file system 
without substantially reducing the availability of the virus checkers for on-access virus checking. 
This novel advantage of applicant's invention is objective evidence of non-obviousness. 

Applicant's New Claims 29-34 

Applicant's new claims 29-34 are directed to applicant's preferred chunk size or 
preferred threshold value, as described in paragraph [00034], lines 18-22 on page 13 of 
applicant's specification: 

[00034] For example, there are ten anti-virus threads in the anti-virus 
thread pool 64, there are five virus checkers, and the chunk size is fifty anti-virus 
file scan requests. The threshold is set to twenty-five. In a more general case of 
"N" virus checkers and "M" anti-virus threads, for example, the chunk size is the 
product (M*N), and the threshold is set to one-half of the chunk size. 

The chunk size is set by a MAX value in step 109 of applicant's FIG. 7, as further described in 
applicant's specification on page 16 lines 18-20. 

Applicant's new claims 29-34 depend on applicant's claims 12, 24, or 27, respectively, 
and therefore applicant's new claims 29-34 distinguish the cited references for at least the 
reasons discussed above with respect to applicant's claims 12, 24, or 27. Moreover, it is 
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respectfully submitted that neither Kouznetsov, Smithson, nor McAfee alone or in combination 
suggest the particular chunk size or threshold specified in applicant's new claims 29-34. 



In view of the above, it is respectfully submitted that the application is in condition for 
allowance. Reconsideration and early allowance are earnestly solicited. 



Respectfully submitted, 

Richard C. Auchterlonie, Reg. No. 30,607 

NOVAK DRUCE & QUIGG, LLP 

1000 Louisiana, 53 rd Floor 

Houston, TX 77002 

Telephone 713-571-3460 

Telefax 713-456-2836 

Richard.Auchterlonie@novakdruce.com 
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